REMARKS 



This Amendment is submitted in response to the Office Action dated October 3, 
2007, having an extended shortened statutory period set to expire March 3, 2008. The 
present amendment proposes amending Claims 1-2, 6-8, 12-14, 18-20, 22, 25-28, 30, 33- 
36, 38 and 41-42, cancelling Claims 6, 12 and 18, and adding Claims 43-46. Upon entry 
of the proposed amendments, Claims 1-4, 7-8, 10, 13-16, 19-23, 25-31, 33-39 and 41-46 
will be pending. 

REJECTIONS UNDER 35 U.S.C. § 112 

In paragraph 4 of the present Office Action, Claims 6, 12 and 18 are rejected 
under 35 U.S.C. § 1 12, first paragraph, for claiming the feature of displaying "only a non- 
text image." Claims 6, 12 and 18 are now cancelled in the present amendment, and thus 
the rejection is moot. 

REJECTIONS UNDER 35 U.S.C. § 103 

In Paragraph 5 of the present Office Action, Claims 1-2, 6-8, 12-14, 18-20, 22, 
25-28, 30, 33-36, 38 and 41-42 are rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Shamoon, et al (U.S. Patent Application Publication No. 
2004/0107356 - "Shamoon") in view of Nicolas et al (U.S. Patent No. 6,593,944 - 
"Nicolas"), hi Paragraph 6 of the present Office Action, Claims 3-4, 10, 15-16, 21, 29 
and 37 are rejected under 35 U.S.C. § 103(a) as being unpatentable over Shamoon and 
Nicolas, and further in view of Dalzell, et al (U.S. Patent Applications Publication No. 
2003/0204447 - "Dalzell"). In Paragraph 7 of the present Office Action, Claims 23, 31 
and 39 are rejected under 35 U.S.C. § 103(a) as being unpatentable over Shamoon and 
Nicolas, and further in view of Mitchell (U.S. Patent No. 6,701,350 - "Mitchell"). 
Applicants respectfully traverse these rejections. 
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With respect to exemplary Claim 1, a combination of the cited art does not teach 
or suggest a "displaying, on the PDA, multiple options, from a billing server to a single 
user of the PDA, for viewing the single web page's content for a price, wherein each 
option has a different price based on how many advertising banners are excluded from 
the single web page's conten t, and wherein one option requires the PDA to display some, 
but not all advertising banners that were originally part of the sin.gle web page's 
content" , as supported in the original specification on page 7, lines 24-29. The Examiner 
cites paragraph [0475] of Shamoon for teaching that a user may have to pay if the user 
wants to view content "without advertisements." The cited passage states: 

[0475] 6. The CMPS arrangement decrypts the MCMPO, and determines the rules 
used to access and use the content. The CMPS arrangement presents the user with 
a set of options, including the ability to view for free with advertisements, or to 
view for a price without advertisements. 

Thus, Shamoon teaches only two options: view with advertisements (for free) or 
view without advertisements (for a price). There is no suggestion of a third, middle 
option, of paying a fee to view only SOME of the advertisements. 

Thus, Applicants request that the rejection of Claims 1, 13, 19, 27 and 35 be 
removed. 

With respect to new Claim 43, a combination of the cited art does not teach or 
suggest "extending a barter offer from the PDA, wherein the barter offer is an offer from 
the single user of the PDA to a proprietor of the web page content, and wherein the offer 
proposes an agreement, between the single user of the PDA and the proprietor of the web 
page content, to provide goods from the single user in exchange for viewing the single 
web page's content on the PDA," as supported in the original specification on page 9, 
lines 20-22. 

With respect to new Claim 44, a combination of the cited art does not teach or 
suggest "extending a barter offer from the PDA, wherein the barter offer is an offer from 
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the single user of the PDA to a proprietor of the web page content, and wherein the offer 
proposes an agreement, between the single user of the PDA and the proprietor of the web 
page content, to provide services from the single user in exchange for viewing the single 
web page's content on the PDA," as supported in the original specification on page 9, 
lines 20-22. 

With respect to new Claim 45, a combination of the cited art does not teach or 
suggest " transcoding the web page content from an HyperText Markup Language 
(HTML) content to a Voice Extensible Markup Language ( VoiceXML) content" 
(supported by page 9, lines 6-9 of the original specification), "wherein the VoiceXML 
content enables the web page content to be aurally presented by the PDA" (supported by 
the attached March 7, 2000 VoiceXML specification describing how "VoiceXML is 
designed for creating audio dialogs that feature synthesized speech" (page 6, first 
paragraph), "and wherein the transcoding is dependent on which option was selected by 
the single user of the PDA" (supported on page 8, line 29 to page 9, line 1 of the present 
specification). 

With respect to new Claim 46, a combination of the cited art does not teach or 
suggest "transcoding the web page content from an HyperText Markup Language 
(HTML) content to a Voice Extensible Markup Language (VoiceXML) content" 
(supported by page 9, lines 6-9 of the original specification), "wherein the transcoding 
depends on which option was selected by the single user of the PDA" (supported on page 
8, line 29 to page 9, line 1 of the present specification). 
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CONCLUSION 



As the cited prior art does not teach or suggest all of the limitations of the pending 
claims, Applicants now respectfully request a Notice of Allowance for all pending 
claims. 

No additional extension of time, beyond that requested above, for this response is 
believed to be necessary. However, in the event an additional extension of time is 
required, that extension of time is hereby requested. Please charge any fee associated 
with such additional extension of time, as well as any other fee necessary to further the 
prosecution of this application, to IBM CORPORATION DEPOSIT ACCOUNT No. 
09-0447. 



Respectfully submitted, 




James E. Boice 

Registration No. 44,545 

DILLON & YUDELL LLP 

8911 North Capital of Texas Hwy. 

Suite 2110 

Austin, Texas 78759 

512.343.6116 



ATTORNEY FOR APPLICANT(S) 
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1 INTRODUCTION 



This document introduces VoiceXML, the Voice Extensible Markup Language. VoiceXML is 
designed for creating audio dialogs that feature synthesized speech, digitized audio, 
recognition of spoken and DTMF key input, recording of spoken input, telephony, and mixed- 
initiative conversations. Its major goal is to bring the advantages of web-based development 
and content delivery to interactive voice response applications. 

Here are two short examples of VoiceXML. The first is the venerable "Hello World": 

<?xml version="1.0"?> 
<vxml version="l . 0"> 
<f orm> 

<block>Hello World !</block> 
</f orm> 
</vxml> 

The top-level element is <vxml>, which is mainly a container for dialogs. There are two types of 
dialogs: forms and menus. Forms present information and gather input; menus offer choices of 
what to do next. This example has a single form, which contains a block that synthesizes and 
presents "Hello World!" to the user. Since the form does not specify a successor dialog, the 
conversation ends. 

Our second example asks the user for a choice of drink and then submits it to a server script: 

<?xml version="l .0"?> 
<vxml version=" 1 . 0"> 
<form> 

<field name=" drink "> 

<prompt>Would you like coffee, tea, milk, or nothing ?< /prompt > 
<grammar s rc=" drink . gram" type="application/x- j sgf " /> 
</field> 
<block> 

<submit next= r, http: / /www. drink. example /drink2 .asp" /> 
</block> 
</f orm> 
</vxml> 

A field is an input field. The user must provide a value for the field before proceeding to the 
next element in the form. A sample interaction is: 

C (computer): Would you like coffee, tea, milk, or nothing? 

H (human}: Orange juice. 

C: I did not understand what you said. 

C: Would you like coffee, tea, milk, or nothing? 

H:Tea 

C: (continues in document drink2.asp) 
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2 BACKGROUND 

This section contains a high-level architectural model, whose terminology is then used to 
describe the goals of VoiceXML, its scope, its design principals, and the requirements it places 
on the systems that support it. 



2.1 Architectural Model 

The architectural model assumed by this document has the following components: 



Document Server 



Request 



Document 



VoiceXML 
Interpreter 
Context 



VoiceXML Interpreter 



Implementation Platform 



Figure 1 Architectural model. 

A document server (e.g. a web server) processes requests from a client application, the VoiceXML 
Interpreter, through the VoiceXML interpreter context. The server produces VoiceXML documents 
in reply, which are processed by the VoiceXML Interpreter. The VoiceXML interpreter context 
may monitor user inputs in parallel with the VoiceXML interpreter. For example, one 
VoiceXML interpreter context may always listen for a special escape phrase that takes the user 
to a high-level personal assistant, and another may listen for escape phrases that alter user 
preferences like volume or text-to-speech characteristics. 

The implementation platform is controlled by the VoiceXML interpreter context and by the 
VoiceXML interpreter. For instance, in an interactive voice response application, the VoiceXML 
interpreter context may be responsible for detecting an incoming call, acquiring the initial 
VoiceXML document, and answering the call, while the VoiceXML interpreter conducts the 
dialog after answer. The implementation platform generates events in response to user actions 
(e.g. spoken or character input received, disconnect) and system events (e.g. timer expiration). 
Some of these events are acted upon by the VoiceXML interpreter itself, as specified by the 
VoiceXML document, while others are acted upon by the VoiceXML interpreter context. 
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